An application platform typically provides basic functions that are required by a multiplicity of applications, e.g. the reading, writing, deleting and archiving of data. Often an application platform also provides a user interface, i.e. functions such as graphical control elements, etc., via which applications can interact with a user for the purpose of inputting and outputting data. An application platform that is specialized for software applications in the medical field often also provides medically relevant basic functions in addition, e.g. algorithms for inspecting, analyzing and processing medical images. The function portfolio that is made available by an—in particular specialized—application platform enables the development time for software applications to be shortened significantly, in particular in the medical environment.
To allow easy access to the functions of an application platform, the latter generally provides what is termed an application programming interface (API) or a plurality of such programming interfaces (APIs), the functions of which can be integrated into the applications that are to be created. Furthermore an application platform sometimes provides what is termed an (application) container in which an application or, in the case of multi-layered applications, a layer of an application runs in encapsulated form. In this case the container controls the execution sequence of the application, in particular the program start and the termination of the application. In addition at least part of the API(s) is typically implemented as a component part of the container. Often, however, the APIs also include additional functions which are implemented independently of the container and which the applications can also access accordingly independently of the container.
The term “function” signifies both here and in the following description in general a functional component of a software program. Such a function can also be realized as a “method” within the context of object-oriented programming or in another form.
By providing a container a correspondingly embodied application platform particularly effectively supports the development of multi-layered, distributed applications, in other words applications that comprise a plurality of mutually independently running parts (layers) which interact with one another via the application platform. In this case medical engineering applications frequently include in particular a so-called frontend layer, the primary purpose of which is interaction with the user, and a so-called backend layer, in which most of the actual calculations are performed. In a computer network, as commonly used these days in medical institutions, the backend layer is in this case implemented mostly in a central server, while the frontend layer is implemented on a client, i.e. a workstation. The application platform is in this case implemented both on the server side and on the client side and also supports the communication between these hardware devices. In this arrangement the frontend layer and the backend layer are encapsulated by the application platform usually in a separate container in each case.
In a typical data processing system of a contemporary medical institution a multiplicity of different medical engineering applications are often implemented on a shared, cross-network application platform. A full or partial update of the application platform, i.e. a change from an older version of the application platform or a part of the platform to a more recent version of the same application platform or part of the platform often proves to be problematic in the case of such a complex system. This is because when there is change of version of an application platform, frequently the specification and/or behavior of an API or a plurality of APIs is also changed to a greater or lesser degree, as a result of which the compatibility of the (new) API(s) with the applications already present before the update is sometimes compromised or destroyed altogether. In order to ensure error-free operation of these applications, the existing applications must in this case be “migrated” to the new platform version, i.e. adapted to match the specification and/or behavior of the new API(s).
Where there are a large number of applications based on a common application platform the amount of effort involved in performing a platform update is often considerable because usually all of the applications must be migrated. In the case of applications which are subdivided into frontend and backend components it is necessary in addition to update both application layers of each application when the application platform is updated. Following the update full tests of every modified application must be run, the tests being particularly exhaustive and time-consuming most notably in the medical field. This causes a heavy workload on the one hand. In the worst case an update of the application platform can also lead to a comparatively long downtime of the medical institution. The development advantage achieved through the use of the application platform is often substantially diminished as a result.